Electronic Version 
Stylesheet Version vl.1.1 

Description 

MEMORY MANAGEMENT METHOD FOR 
STORING MOTION VECTORS OF 
DECODED MACROBLOCKS 

Background of Invention 

[0001] 1. Field of the Invention 

[0002] The present invention provides a memory management 
method for storing motion vector(s) of decoded mac- 
roblocks, and more particularly, to a memory manage- 
ment method for storing motion vector(s) of decoded 
macroblocks for providing candidate predictors in future 
decoding processes. 

[0003] 2. Description of the Prior Art 

[0004] The motion picture experts group (MPEG) was established 
in 1988 and is a working group of the international orga- 
nization for standardization (ISO). This working group has 
set up several audio/video compression formats of differ- 
ent versions. MPEG-1 and MPEG-2 are two video com- 



pression standards widely used today, and these two 
video compression standards liave some common points. 
When processing video encoding/decoding with the MPEG 
standards, a 16*16 pixel macroblock (MB) is the basic unit 
for dealing with motion vectors (MV). In the MPEG stan- 
dards, a macroblock can have a single motion vector for 
the whole macroblock, and in such situation the mac- 
roblock is called a "large region". Or, a macroblock can be 
composed of four 8*8 blocks with each block having its 
own motion vector. In such situation, each 8*8 block is 
called a "small region". Additionally, a macroblock can be 
composed of two fields, each field having its own motion 
vector. In this situation, each field is called a "field re- 
gion". 

[0005] A video frame ( in MPEG-4 standard a video frame is also 
called a VOP, which stands for video object plane) can be 
a progressive frame or an interlaced frame. A progressive 
frame may be irregularly composed of the above- 
mentioned large regions and small regions. Fig.l shows 
an example of a progressive frame. An interlaced frame is 
irregularly composed of the above-mentioned large re- 
gions, small regions and field regions. Fig. 2 shows an ex- 
ample of an interlaced frame. Note that in Fig.l and Fig. 2, 



110 is a large region, 115 is tlie motion vector of tlie 
large region, 130 is a small region, 135 is the motion vec- 
tor of the small region, 150 is a field region, and 155 is 
the motion vector of the field region. 
[0006] When processing motion compensation (MC), motion vec- 
tors must be decoded. Taking MPEG-4 standard as an ex- 
ample, P-VOP (which stands for predicted VOP) and 
S(CMC)-VOP (which stands for sprite global motion com- 
pensation VOP) are two kinds of video object planes that 
are encoded through using motion vectors. For decoding 
a motion vector of this kind of video object planes, the 
horizontal and vertical motion vector components are de- 
coded differentially using a prediction. The prediction is 
formed by a median filtering of three vector candidate 
predictors from spatial neighborhood macroblocks or 
blocks already decoded. In the following description, 
when a macroblock contains only one motion vector for 
the whole macroblock, it will be referred to as a type-1 
macroblock; when a macroblock contains four blocks (a 
first block in the top-left corner, a second block in the 
top-right corner, a third block in the bottom-left corner, 
and a fourth block in the bottom-right corner) and four 
corresponding motion vectors, it will be referred to as a 



type-2 macroblock; and when a macroblock contains two 
fields (a first field and a second field) and two corre- 
sponding motion vectors, it will be referred to as a type-3 
macroblock. 

[0007] When the video frame being decoded is a progressive 

frame, it is possible that the decoding macroblock and the 
spatial neighborhood macroblocks for providing candidate 
predictors are all type-1 macroblocks. This situation is 
shown in Fig. 3, where macroblocks A, B, C, X are all type- 
1 macroblocks. When decoding the motion vector of mac- 
roblock X, the motion vectors of the spatial neighborhood 
macroblocks A, B, and C are used as candidate predictors 
to determine the motion vector predictor of macroblock X. 
The predictor for the horizontal component (Px) and verti- 
cal component (FV) are computed by: 

[0008] Px = Median (MVlx,MV2x,MV3x) 

[0009] py = Median (MVly,MV2y,MV3y) 

[0010] where Median is a function for determining a median. For 
example, when MVl=(-2,3), MV2=(1,5), MV3=(-1,7), Px 
and Py are -1 and 5, respectively. 

[0011] When the video frame being decoded is a progressive 
frame, it is also possible that the decoding macroblock 



and the spatial neighborhood macroblocl<s for providing 
candidate predictors are all type-2 macroblocks. These 
situations are shown in Fig. 4, Fig. 5, Fig. 6, and Fig. 7. 
Please first refer to Fig. 4. When decoding the motion vec- 
tor of macroblock X's first block, the motion vector of 
macroblock A's second block, the motion vector of mac- 
roblock B's third block, and the motion vector of mac- 
roblock C's third block are used as candidate predictors. 
Please refer to Fig. 5. When decoding the motion vector of 
macroblock X's second block, the motion vector of mac- 
roblock X's first block (already decoded), the motion vec- 
tor of macroblock B's fourth block, and the motion vector 
of macroblock C's third block are used as candidate pre- 
dictors. Please next refer to Fig. 6. When decoding the mo- 
tion vector of macroblock X's third block, the motion vec- 
tor of macroblock A's fourth block, the motion vectors of 
macroblock X's first and second blocks (already decoded) 
are used as candidate predictors. Please next refer to 
Fig. 7. When decoding the motion vector of macroblock X's 
fourth block, the motion vectors of macroblock X's first, 
second, and third blocks (already decoded) are used as 
candidate predictors. The method of calculation is the 
same as previously mentioned, specifically: 



[0012] px = Median (MVlx,MV2x,MV3x); 
[0013] py = Median (MVly,MV2y,MV3y). 

[0014] wiien tlie video frame being decoded is an interlaced 

frame, it is possible that the decoding macroblock or the 
spatial neighborhood macroblocks for providing candidate 
predictors are type-3 macroblocks. These situations are 
as shown in Fig. 8, Fig. 9, and Fig. 10. Please first refer to 
Fig. 8. The decoding macroblock X is a type-3 macroblock, 
while macroblocks A, B, C are type-2 macroblocks. When 
decoding the motion vectors of macroblock X's first field 
and second field, the motion vector of macroblock A's 
second block, the motion vector of macroblock B's third 
block, and the motion vector of macroblock Cs third 
block are used as candidate predictors. Please next refer 
to Fig. 9. One or more macroblock(s) of A, B, C (in this ex- 
ample, macroblock B) is a type-3 macroblock, and has two 
motion vectors MV2fl and MV2f2. In this situation the 
candidate predictors MV2x and MV2y provided by mac- 
roblock B are computed as follows: 

[0015] MV2x = Div2Round (MV2x_fl,MV2x_f2) 

[0016] MV2y = Div2 Round (MV2y_fl,MV2y_f2) 

[0017] where Div2Round is an average then carry function. For 



example, when MV2x_fl=(l,2), MV2x_f2=(4,5), MV2x and 
MV2y are 3 and 4 respectively. After MV2 is calculated, Px 
and FV can be determined through the above-mentioned 
Median function. Please refer to Fig. 10. Macroblocks A, B, 
C, and X are all type-3 macroblocks. In this situation the 
candidate predictors MVl, MV2, and MV3 provided by 
macroblock A, B, and C are all determined through the 
above-mentioned Div2Round function, specifically: 
[0018] MVix = Div2Round (MVix_fl,MVix_f2) 

[0019] MViy = Div2Round (MViy_fl,MViy_f2), where i={l, 2, 3} 

[0020] The motion vector predictor Px and Py for both the first 
and second field of macroblock X can then be determined 
through the above-mentioned Median function. 

[0021] Please refer to Fig. 11 showing a conventional system for 
processing motion compensation. The system shown in 
Fig. 11 is an integrated system for processing progressive 
frames and interlaced frames. The variable length decoder 
(VLD) 210 is for computing a differential motion vector 
Diff. The multiplexer 250 is for determining how to pro- 
vide candidate predictors according to VOP.Type (i.e. 
whether the video frame is a progressive frame or an in- 
terlaced frame). Multiplexers 251, 254 are for selecting a 



candidate predictor provided by macroblocl< A according 
to IVIB_A_Type. l\/lultiplexers 252, 255 are for selecting a 
candidate predictor provided by macroblock B according 
to l\/IB_B_Type. l\/lultiplexers 253, 256 are for selecting a 
candidate predictor provided by macroblock C according 
to MB_C_Type. Prediction filters 220 and 221 are for de- 
termining a motion vector predictor (Predictor) by median 
filtering of the candidate predictors. Filters 261, 262, 263 
are responsible for the Div2Round function. Motion vector 
calculator (MV_CAL) 230 is then used for determining pre- 
diction differences between video frames according to Diff 
and Predictor. Finally, the motion compensator (MC) 240 
can perform motion compensation according to the result 
computed by the motion vector calculator 230. 
[0022] Because before designing the system, it is not certain 
which type macroblocks A, B, C will be, while allocating 
memory space, three different situations of three spatial 
neighborhood macroblocks should be considered. This 
means, for each macroblock A, B, and C, the system 
should allocate a memory space being sufficient for stor- 
ing a single motion vector of a macroblock (for dealing 
with the situation when the macroblock is a type-1 mac- 
roblock), four memory spaces each being sufficient for 



storing a motion vector of a blocic (for dealing witli tlie 
situation when the macroblocl< is a type-2 macroblock), 
and two memory spaces each being sufficient for storing a 
motion vector of a field (for dealing with the situation 
when the macroblock is a type-3 macroblock). In other 
words, for each macroblock to provide a candidate pre- 
dictor, the system should allocate seven memory spaces 
each being sufficient for storing a motion vector. 
[0023] The conventional memory allocating method consumes a 
lot of memory space. When decoding motion vectors, sys- 
tems of the prior art consider each video frame as a 
whole. In other words, taking a frame with 720*480 pixels 
as an example, when storing motion vector(s) of each de- 
coded macroblock (which will become macroblock B and C 
for future decoding of macroblock X), the system must al- 
locate (720/16)*(480/16)*7 memory spaces in a first 
memory. When storing motion vector(s) of each decoded 
macroblock (which will become macroblock A for future 
decoding of macroblock X), the system must allocate 
seven memory spaces in a second memory. This method 

is costly and is not ideal for system implementation. 
Summary of Invention 

[0024] It is therefore an object of the invention to provide a 



memory management method for storing motion vector(s) 
of decoded macroblocl<s to solve the above-mentioned 
problem. 

[0025] According to the embodiment, a memory management 
method used in the decoding process of a video frame is 
disclosed. The method is for storing motion vector(s) of a 
decoded first macroblock as candidate predictor(s) for fu- 
ture use in the decoding process, and includes the follow- 
ing steps: allocating a first memory space and a second 
memory space in a first memory, wherein each of the first 
and the second memory spaces is sufficient for storing 
one motion vector; and when the first macroblock has 
only one first motion vector, storing the first motion vec- 
tor in the first or the second memory space. 

[0026] The embodiment also discloses a memory management 
method used in the decoding process of a video frame. 
The method is for storing the motion vector(s) of a de- 
coded first macroblock as candidate predictor(s) for use in 
decoding a next macroblock. The method includes: allo- 
cating a third memory space and a fourth memory space 
in a second memory, wherein each of the third and the 
fourth memory spaces is sufficient for storing one motion 
vector; and when the first macroblock has only one first 



motion vector, storing the first motion vector in the third 
or the fourth memory space. 
[0027] Additionally, the embodiment also suggest a memory 
reuse implementation method. That is, when allocating 
memory space in the first memory, the embodiment con- 
siders each row of macroblocks as a whole. A plurality of 
memory units sufficient for storing motion vectors of a 
row of macroblocks are allocated, and are reused each 
time a new row is decoded. In this way, the embodiment 
greatly saves memory resources comparing to the prior 
art. 

[0028] These and other objectives of the present invention will no 
doubt become obvious to those of ordinary skill in the art 
after reading the following detailed description of the pre- 
ferred embodiment that is illustrated in the various fig- 
ures and drawings. 
Brief Description of Drawings 

[0029] Fig i is an example of a progressive frame. 

[0030] Fig. 2 is an example of an interlaced frame. 

[0031] Fig. 3 shows a situation when macroblocks A, B, C, and X 

are all type-1 macroblocks. 
[0032] Fig. 4 shows a first situation when macroblocks A, B, C, 



and X are all type-2 macroblocks. 
[0033] Fig. 5 shows a second situation when macroblocks A, B, C, 

and X are all type-2 macroblocks. 
[0034] Fig. 6 shows a third situation when macroblocks A, B, C, 

and X are all type-2 macroblocks. 
[0035] Fig. 7 shows a fourth situation when macroblocks A, B, C, 

and X are all type-2 macroblocks. 
[0036] Fig. 8 shows a first situation when macroblocks A, B, C, 

and X comprise at least one type-3 macroblock. 
[0037] Fig. 9 shows a second situation when macroblocks A, B, C, 

and X comprise at least one type-3 macroblock. 
[0038] Fig. 10 shows a situation when macroblocks A, B, C, and X 

are all type-3 macroblocks. 
[0039] Fig. 11 is a conventional system for processing motion 

compensation. 

[0040] Fig. 12 is a first flowchart according to a first embodiment 
of the present invention. 

[0041] Fig. 13 is a second flowchart according to a second em- 
bodiment of the present invention. 

[0042] Fig. 14 is a third flowchart according to a third embodi- 
ment of the present invention. 

[0043] Fig. 15 is a system for processing motion compensation 
with the method provided by the present invention. 



Detailed Description 

[0044] Referring to Fig.3~Fig.lO, when decoding tlie motion vec- 
tor(s) of a macroblock X, two already decoded mac- 
roblocks on a previous row (that is the row directly above 
macroblock X) will be used as a macroblock B and a mac- 
roblock C to provide candidate predictors. In other words, 
for each decoded macroblock, when a macroblock on a 
next row (that is the row directly beneath the decoded 
macroblock) is going to be decoded, it is possible that the 
decoded macroblock will be used as a macroblock B or a 
macroblock C to provide candidate predictor(s). Hence, 
each time when a macroblock is decoded, its motion vec- 
tor(s) should be stored, in case the motion vector(s) will 
be used as candidate predictor(s) in future decoding pro- 
cess (when decoding macroblocks on the next row). To 
deal with ssuch situation through the conventional 
method, seven memory spaces each being sufficient for 
storing one motion vector are allocated for each decoded 
macroblock (note that before designing the system, it is 
not certain which type a decoded macroblock will be). 
However, in actuality, if the decoded macroblock is a 
type-1 macroblock, saving only one motion vector of the 
whole macroblock will be enough (because a type-1 mac- 



roblock has only motion vector). If the decoded mac- 
roblock is a type-2 macroblock, saving two motion vec- 
tors of the macroblock (specifically, the motion vectors of 
the third and fourth blocks) will be enough, because only 
these two motion vectors are possible to be used as can- 
didate predictors when decoding macroblocks on the next 
row. If the decoded macroblock is a type-3 macroblock, 
saving two motion vectors (the motion vectors of the first 
and second fields) of the macroblock will be enough, be- 
cause the candidate predictor used in decoding mac- 
roblocks on the next row can be determined through ap- 
plying Div2Round function on the two stored motion vec- 
tors. In conclusion, to deal with this situation, no matter 
what type the decoded macroblock belongs to, allocating 
two memory spaces (each being sufficient for storing one 
motion vector) for each decoded macroblock is enough. 

[0045] Fig. 12 shows a flowchart according to a first embodiment 
of the present invention. The flowchart shown in Fig. 12 
includes the following steps: 

[0046] 510: Allocate a first memory space and a second memory 
space in a first memory for a decoded first macroblock re- 
gardless of whether the first macroblock is a type-1, 
type-2, or type-3 macroblock. Each of the first memory 



space and the second memory space is sufficient for stor- 
ing a motion vector. 

[0047] 520: Determine tlie type of tlie first macroblock. When the 
first macroblocl< is a type-1 macroblocl<, go to step 630; 
when the first macroblocl< is a type-2 macroblocl<, go to 
step 640; and when the first macroblocl< is type-3 mac- 
roblock, go to step 650. 

[0048] 530: The first macroblock is a type-1 macroblock having 
a first motion vector. Store the first motion vector in the 
first or the second memory spaces. Although one memory 
space is enough for storing the first motion vector under 
this situation, it is also practicable to store the first mo- 
tion vector in both the first and the second memory 
spaces. 

[0049] 540: The first macroblock is a type-2 macroblock having 
four blocks. Store the motion vector of the first mac- 
roblock's third block in the first memory space, and store 
the motion vector of the first macroblock's fourth block in 
the second memory space. 

[0050] 550: The first macroblock is a type-3 macroblock having 
a first field and a second field. Store the motion vector of 
the first macroblock's first field in the first memory space, 
and store the motion vector of the first macroblock's sec- 



ond field in tlie second memory space. 
[0051] Specifically, this flowchart shows an embodiment of the 
present invention explaining how to allocate memory 
spaces and how to use the allocated memory spaces to 
store the motion vector(s) of the decoded first mac- 
roblock, considering the possibility that the motion vec- 
tor(s) of the first macroblock will be used as candidate 
predictor(s) when macroblocks on the next row is going to 
be decoded. 

[0052] By using the flowchart shown in Fig. 12, no matter what 
type the decoded first macroblock belongs to, when de- 
codeing macroblocks on the next row, candidate predic- 
tor(s) can be determined according to the motion vectors 
stored in the first and second memory spaces. More 
specifically, when the first macroblock is a type-1 mac- 
roblock, the candidate predictor provided by the first 
macroblock could be the one stored in the first or the 
second memory space (these two motion vectors are the 
same). When the first macroblock is a type-2 macroblock, 
the candidate predictor provided by the first macroblock 
could be the one stored in the first memory space (if the 
motion vector of the third block is used as the candidate 
predictor), or the one stored in the second memory space 



(if the motion vector of tlie fourtli blocl< is used as tlie 
candidate predictor). Wlien tlie first macroblocl< is a type- 
3 macroblock, tlie candidate predictor provided by the 
first macroblocic could be determined though applying 
Div2Round function on the two motion vectors stored in 
the first and second memory spaces. 

[0053] Please note that the first memory can be implemented by 
a dynamic random access memory (DRAM), a static ran- 
dom access memory (SRAM), registers, or other devices 
capable of storing data. 

[0054] Furthermore, referring to Fig.3~Fig.lO, when decoding the 
motion vector(s) of macroblock X, an already decoded 
macroblock on the left of macroblock X will be used as a 
macroblock A to provide candidate predictor(s). In other 
words, for each decoded macroblock, when a next mac- 
roblock (that is the macroblock on the right of the de- 
coded macroblock) is going to be decoded, the decoded 
macroblock will be used as a macroblock A to provide 
candidate predictor(s). Hence, each time when a mac- 
roblock is decoded, its motion vector(s) will be stored, in 
case the motion vector(s) will be used as candidate pre- 
dictor(s) in decoding a next macroblock. To deal with this 
situation using the conventional method, seven memory 



spaces each being sufficient for storing one motion vector 
must be allocated for each decoded macroblock (note that 
when designing the system, it is not certain which type a 
decoded macroblock will be). However, in actuality, if the 
decoded macroblock is a type-1 macroblock, saving only 
one motion vector of the whole macroblock will be 
enough (because a type-1 macroblock has only motion 
vector). If the decoded macroblock is a type-2 mac- 
roblock, saving two motion vectors (the motion vectors of 
the second and fourth blocks) of the macroblock will be 
enough, because only these two motion vectors are possi- 
ble to be used as candidate predictors when decoding a 
next macroblock. If the decoded macroblock is a type-3 
macroblock, saving two motion vectors (the motion vec- 
tors of the first and second fields) of the macroblock will 
be enough, because the candidate predictor used in de- 
coding the next macroblocks can be determined through 
applying Div2Round function on the two stored motion 
vectors. In conclusion, to deal with this situation, no mat- 
ter what type the decoded macroblock belongs to, allocat- 
ing two memory spaces (each being sufficient for storing 
one motion vector) for each decoded macroblock is 
enough. 



[0055] Fig. 13 shows a flowchart according to a second embodi- 
ment of the present invention. The flowchart shown in 
Fig. 13 contains the following steps: 

[0056] 710: Allocate a third memory space and a fourth memory 
space in a second memory for a decoded first macroblock 
regardless of whether the first macroblock is a type-1, 
type-2, or type-3 macroblock. Each of the third memory 
space and the fourth memory space is sufficient for stor- 
ing a motion vector. 

[0057] 720: Determine the type of the first macroblock. When the 
first macroblock is a type-1 macroblock, go to step 730; 
when the first macroblock is a type-2 macroblock, go to 
step 740; when the first macroblock is type-3 mac- 
roblock, go to step 750. 

[0058] 730: The first macroblock is a type-1 macroblock having 
a first motion vector. Store the first motion vector in the 
third or the fourth memory space. Although one memory 
space is enough for storing the first motion vector under 
this situation, it is also practicable to store the first mo- 
tion vector in both the third and the fourth memory 
spaces. 

[0059] 740: The first macroblock is a type-2 macroblock having 
four blocks. Store the motion vector of the first mac- 



roblocks second block in the third memory space, and 
store the motion vector of the first macroblocks fourth 
block in the fourth memory space. 

[0060] 750: The first macroblock is a type-3 macroblock having 
a first field and a second field. Store the motion vector of 
the first macroblock's first field in the third memory 
space, and store the motion vector of the first mac- 
roblock's second field in the fourth memory space. 

[0061] Specifically, this flowchart shows an embodiment of the 
present invention explaining how to allocate memory 
spaces and how to use the allocated memory spaces to 
store the motion vector(s) of the decoded first mac- 
roblock, considering that the motion vector(s) of the first 
macroblock will be used as candidate predictor(s) when a 
next macroblocks is going to be decoded. 

[0062] By using the flowchart shown in Fig. 13, no matter what 
type the decoded first macroblock belongs to, when de- 
coding a next macroblock, candidate predictor(s) can be 
determined according to the motion vectors stored in the 
third and fourth memory spaces. More specifically, when 
the first macroblock is a type-1 macroblock, the candi- 
date predictor provided by the first macroblock could be 
the one stored in the third or the fourth memory space 



(these two motion vectors are the same). When the first 
macroblocic is a type-2 macroblocl<, the candidate predic- 
tor provided by the first macroblock could be the one 
stored in the third memory space (if the motion vector of 
the second blocl< is used as the candidate predictor), or 
the one stored in the fourth memory space (if the motion 
vector of the fourth blocl< is used as the candidate predic- 
tor). When the first macroblocl< is a type-3 macroblocl<, 
the candidate predictor provided by the first macroblock 
could be determined though applying Div2Round function 
on the two motion vectors stored in the third and fourth 
memory spaces. 

[0063] Please note that the second memory can be implemented 
by a dynamic random access memory (DRAM), a static 
random access memory (SRAM), registers, or other devices 
capable of storing data. Additionally, the first memory and 
the second memory can be realized as two separate mem- 
ory devices or a single memory device, as can be appreci- 
ated by people familiar with the related arts. 

[0064] Aside from macroblocks located on the last row and the 
last column of each video frame (or VOP), every decoded 
macroblock will have to provide its motion vector(s) as 
candidate predictor(s) for decoding a next macroblock 



and for decoding macroblocks on a next row. Hence, for 
each of these macroblocks, both the flowchart shown in 
Fig. 12 and Fig. 13 could be used to allocate memory 
spaces to store its motion vector(s). For those decoded 
macroblocks located on the last row of each frame (except 
for the last macroblock of the whole video frame), their 
motion vector(s) will not be used as candidate predictor(s) 
when macroblocks on a next row are going to be decoded 
(because the last row does not have a "next row" in the 
video frame). Hence using only the flowchart shown in 
Fig. 13 would be enough. For those decoded macroblocks 
located on last column of each frame (except for the last 
macroblock of the whole video frame), their motion vec- 
tors will not be used as candidate predictor(s) when a next 
macroblocks on the same row is going to be decoded 
(because there is no "next macroblock" located on the 
same row). Hence using only the flowchart shown in 
Fig. 12 would be enough. For the last macroblock of the 
whole video frame, its motion vectors will not be used as 
candidate predictor(s) and therefore need not be stored. 
[0065] In addition to the flowcharts shown in Fig. 12 and Fig. 13, 
the present invention also contains the idea of memory 
reuse. In the prior art, when allocating memory space for 



storing motion vectors, each video frame is considered as 
a whole. However, in the present invention, the row of the 
macroblock rather than the entire video frame is consid- 
ered as a whole. Please refer to Fig. 14 showing a 
flowchart according to a third embodiment of the present 
invention. The flowchart shown in Fig. 14 contains the fol- 
lowing steps: 

[0066] 310: Allocate N memory units in a first memory, and allo- 
cate an additional memory unit in a second memory. Each 
one of the N memory units in the first memory and the 
additional memory unit in the second memory is sufficient 
for storing motion vector(s) of a single macroblock. More 
specifically, the N memory units are used to store motion 
vectors of a row of macroblocks, in case the stored mo- 
tion vectors will be used as candidate predictors when 
macroblocks on a next row are going to be decoded. 
Hence each of the N memory unit could contain a first and 
a second memory space as described in Fig. 12. And the 
additional memory unit is used to store motion vector(s) 
of each decoded macroblock in case the motion vector(s) 
of the decoded macroblock will be used as candidate pre- 
dictor(s) when a next macroblock is going to be decoded. 
Hence the additional memory unit could contain a third 



and a fourth memory space as described in Fig. 13. 

th th 

[0067] 320: A macroblocl< at the L row and K column is de- 
coded. 

[0068] 830: Is L>1? If yes, go to step 850, otherwise go to step 
840. 

[0069] 840: The decoded macroblock is located at a first row of a 
video frame. Store the motion vector(s) of the decoded 
macroblock in a K**^ memory unit of the N memory units in 
the first memory, and store the motion vector(s) of the 
decoded macroblock in the additional memory unit in the 
second memory. Under the condition that each of the N 
memory unit contains a first and a second memory space 
described in Fig. 12 and the additional memory unit con- 
tains a third and a fourth memory space described in 
Fig. 13. If the decoded macroblock is a type-1 macroblock, 
its motion vectors could be stored in the first or the sec- 
ond memory spaces (or be stored in both of these two 
memory spaces), and stored in the third or the fourth 
memory spaces (or be stored in both of these two memory 
spaces). If the decoded macroblock is a type-2 mac- 
roblock, the motion vector of its second block could be 
stored in the third memory space, the motion vector of its 
third block could be stored in the first memory space, and 



the motion vector of its fourth blocl< could be stored in 
the second and fourth memory spaces. If the decoded 
macroblock is a type-3 macroblock, the motion vector of 
its first field could be stored in the first and third memory 
spaces, and the motion vector of its second field could be 
stored in the second and fourth memory spaces. In this 
way, each time a macroblock is decoded, its motion vec- 
tor(s) will always been stored in the additional memory 
unit in the second memory, overwriting the motion vec- 
tor(s) of a previously decoded macroblock, so the addi- 
tional memory unit in the second memory will be reused 
once each time a macroblock is decoded. And at this time 
each of the 1^*~K*^ memory units of the N memory units in 
the first memory is stored with the motion vector(s) of the 
l^^'-K^'^ macroblocks of the 1^* row respectively; each of 

th th 

the(K+l) ~N memory units of the N memory units in 
the first memory is empty or stored with the motion vec- 
tors of macroblocks in a previous decoded video frame 
(which will not be used as candidate predictors in decod- 
ing this video frame); the additional memory unit in the 
second memory is stored with the motion vector(s) of the 
(K-l)^"^ macroblocks of the 1^* row (when K>1), or stored 
with the motion vector(s) of a macroblock in the previous 



decoded video frame (which will not be used as candidate 
predictors in decoding this video frame). 

th 

[0070] 850: The decoded macroblock is located at an L row of 
the video frame (L>1). Store the motion vector(s) of the 
decoded macroblock in a K**^ memory unit of the N mem- 
ory units in the first memory, and store the motion vec- 
tor(s) of the decoded macroblock in the additional mem- 
ory unit in the second memory. Again, under the condition 
that each of the N memory unit contains a first and a sec- 
ond memory unit described in Fig. 12 and the additional 
memory unit contains a third and a fourth memory space 
described in Fig. 13. If the decoded macroblock is atype-1 
macroblock, its motion vectors could be stored in the first 
or the second memory spaces (or be stored in both of 
these two memory spaces), and stored in the third or the 
fourth memory spaces (or be stored in both of these two 
memory spaces). If the decoded macroblock is a type-2 
macroblock, the motion vector of its second block could 
be stored in the third memory space, the motion vector of 
its third block could be stored in the first memory space, 
and the motion vector of its fourth block could be stored 
in the second and fourth memory spaces. If the decoded 
macroblock is a type-3 macroblock, the motion vector of 



its first field could be stored in the first and third memory 
spaces, and the motion vector of its second field could be 
stored in the second and fourth memory spaces. In this 
way, when L>1, the motion vector(s) of decoded mac- 

th th 

roblock at L row and K column will be stored at the 
memory unit originally storing the motion vector(s) of a 

th th 

previously decoded macroblock at the (L-1) row and K 
column. That is, the motion vector(s) of macroblock at 

th th 

(L-1) row and K column will be overwritten by the mo- 

th th 

tion vector(s) of macroblock at L row and K column. In 
other words, the N memory units in the first memory will 
be reused once each time a row of macroblocks is de- 
coded. And at this time each of the l^^'-K^'^ memory units 
of the N memory units in the first memory is stored with 
the motion vector(s) of the l^^'-K*'^ macroblocks of the L**^ 

th th 

row respectively; each of the (K+1) ~N memory units of 
the N memory units in the first memory is stored with the 

th th 

motion vector(s) of the (K+1) ~N macroblocks of the 

th 

(L-1) row respectively; the additional memory unit in the 
second memory is stored with the motion vector(s) of the 
(K-l) macroblocks of the L row (when K>1), or stored 

th 

with the motion vector(s) of the N macroblocks of the 

th 

(L-1) row (which will not be used as candidate predictors 



in decoding macroblocl<s at the L row). 
[0071] 350: If the decoding process is not finished, return to step 
820. 

[0072] Using the row based memory reuse scheme provided by 
the present invention, at each time point what the system 
must store are motion vectors of a row of macroblocks 
and a previous decoded macroblock. Taking a video frame 
with 720*480 pixels as an example, by using the method 
provided by the present invention, the system has to allo- 
cate only (720-rl6) memory units (that is, (720-^16)x2 
memory spaces) in the first memory and one memory unit 
(that is, two memory spaces) in the second memory (each 
allocated memory space being sufficient for storing one 
motion vector). Compared with the prior art, by using the 
method provided by the present invention, memory re- 
sources are used more efficiently. 

[0073] Next, please refer to Fig. 15 showing a system for pro- 
cessing motion compensation with a method provided by 
the present invention. The system configuration shown in 
Fig. 15 is similar to that shown in Fig. 11, a major differ- 
ence is that by using the method provided by the present 
invention, the system only has to allocate two memory 
spaces for each of macroblock A, B, and C. Where each al- 



located memory space is sufficient for storing a motion 
vector. l\/IB_A_Type, l\/IB_B_Type, and l\/IB_C_Type are se- 
lecting signals according to macroblocks A, B, and Cs 
type. Taking macroblock A as an example, when mac- 
roblock A is a type-1 macroblock, each one of the two 
memory spaces allocated for macroblock A can provide 
the proper motion vector as a candidate predictor. When 
macroblock A is a type-2 macroblock, one of the two 
memory spaces allocated for macroblock A can provide 
the proper motion vector as a candidate predictor 
(depends on the motion vector of macroblock A's second 
or fourth block will be used as the candidate predictor). 
When macroblock A is a type-3 macroblock, by applying 
Div2 Round function on the two motion vectors stored in 
the two memory spaces allocated for macroblock A, the 
filter 451 can provide the proper motion vector as candi- 
date predictor. 

[0074] Please note that the system shown in Fig. 15 can handle 

motion compensation for both progressive frames and in- 
terlaced frames. However, a system designer can also de- 
sign a system simply for handling motion compensation 
for only progressive frames or only interlaced frames ac- 
cording to the method provided by the present invention. 



[0075] In contrast to the conventional system, a system employ- 
ing the present invention uses less memory space, which 
means the memory is used more efficiently. Hence system 
resources are saved. 

[0076] Those skilled in the art will readily observe that numerous 
modifications and alterations of the device and method 
may be made while retaining the teachings of the inven- 
tion. Accordingly, the above disclosure should be con- 
strued as limited only by the metes and bounds of the ap- 
pended claims. 



